Mobile radio networks are proposed for enhanced data transmissions and integration with multimedia IP services, and more precisely GSM/EDGE delay-sensitive applications (referenced acronyms are listed at the end of the description).
FIG. 1 shows the functional architecture of a GSM/EDGE network according to 3GPP TS 44.060. The depicted network includes the following functional blocks: MSs (TE and MT), BSS (both BTSs and BSC), SGSN, GGSN, EIR, MSC/VLR, HLR, SMS-GMSC, SMS-IWMSC, and SM-SC. Inside the MS the first functional block TE is connected to the second functional block MT through a connection indicated by a Reference point R, typically supporting a standard serial interface. The following interfaces are foreseen: Um, A-bis, A, Gb, Gi, Gp, Gn, Gp, Gf, Gs, Gr, Gd, D, E, C, whose connectivity between the relevant blocks are directly visible in the figure.
Every MS (MT) is connected to its serving BTS through the Um radio interface for exchanging voice and data services and the relevant signaling. The BSS includes a plurality of BTS connected to a BSC through a respective A-bis interface. The BSC is connected to the core network, mainly including MSC and SGSN, through the A and Gb interfaces accounting for circuit switched domain (CS) and packet switched domain (PS), respectively. Former BSSs are evolved in GERANs in order to allow higher data throughputs and incremental redundancy when erroneous data blocks are retransmitted. Furthermore, the Gn interface connects two GSN nodes in the same PLMN system, while the Gp interface connects two GSN nodes belonging to different PLMN systems. In operation, the sub-set of MAC procedures governing the multiplexing of the transmissions on shared channels provides the MS with temporary assignment of resources on the physical layer to sustain the single transmission. Resources are assigned for each so-called UL/DL TBF associated to the MS. More detailed notions on TBFs and network operation are given later in the description.
3GPP Technical Specifications are being improved to support advanced services. A main target for GERAN is to support real-time multimedia services over IP using the GPRS capability, e.g. VoIP, TV channels, combinational services, etc. In order to get an end-to-end delay sufficiently low to provide a “real-time interaction” between users, the network transmission delay (latency) shall be reduced as much as possible. Some new mechanisms have been recently introduced in the RLC/MAC protocol to reduce latency and guarantee a good voice quality. A first one is based on TTI reduction. A reduced TTI (say of 10 ms, instead of 20) would reduce the RLC RTT, thus allowing the possibility to perform retransmissions fast enough to maintain the end-to-end delay requirements. A second mechanism is the non-persistent mode of transmission, as defined in 3GPP TS 44.060, V7.3.0 (2006-01), Release 7; see for example:                Section 9—RLC procedures in packet transfer mode;        clause 9.1—Procedures and parameters for peer-to-peer operation;        subclause 9.1.12—Re-assembly of upper layer PDUs from RLC data units.        
The transmission/reception window is a fundamental concept valid in general both for persistent and non-persistent mode of transmission. The following related terms apply:                WS=Window Size: 64 to 1024 in EGPR; 64 in GPRS.        SNS=Sequence Number Space: 2048 in EGPRS, and 128 in GPRS.        BSN—Block sequence number (subclause 9.1.4.2). Each RLC data block contains a block sequence number (BSN) field that is 11 bits in length. At the time that an in-sequence RLC data block is designated for transmission, the value of BSN is set equal to the value of the send state variable V(S).        V(S)—Send state variable (subclause 9.1.1). Each RLC endpoint transmitter shall have an associated send state variable V(S). V(S) denotes the sequence number of the next in-sequence RLC data block to be transmitted. V(S) can take on the value 0 through SNS −1. V(S) shall be set to the value 0 at the beginning of each TBF in which the RLC endpoint is the transmitter. The value of V(S) shall be incremented by 1 after transmission of the RLC data block with BSN=V(S). In RLC acknowledged mode, V(S) shall not exceed V(A) modulo SNS by more than the maximum allowed number of outstanding RLC data blocks WS. In RLC non-persistent mode, V(S) may be incremented independently on the value of V(A).        V(A)—Acknowledge state variable (see subclause 9.1.2). In RLC acknowledged mode, each RLC endpoint transmitter shall have an associated acknowledge state variable V(A). V(A) contains the BSN value of the oldest RLC data block that has not been positively acknowledged by its peer. V(A) can take on the values 0 through SNS −1. V(A) shall be set to the value 0 at the beginning of each TBF in which the RLC endpoint is the transmitter. The value of V(A) shall be updated from the values received from its peer in the received block bitmap (RBB) of the Packet Ack/Nack message.        V(R)—Receive state variable (see subclause 9.1.5). Each RLC endpoint receiver shall have an associated receive state variable V(R). The receive state variable denotes the BSN which has a value one higher than the highest BSN yet received (modulo SNS). V(R) shall be set to the value <1>O<1> at the beginning of each TBF in which the RLC endpoint is the receiver. V(R) can take on the value 0 through SNS.        V(Q)—Receive window state variable (see subclause 9.1.6). Each RLC endpoint receiver shall have an associated receive window state variable V(Q). The receive window state variable denotes the lowest BSN not yet received (modulo SNS), therefore representing the start of the receive window. V(Q) shall be set to the value 0 at the beginning of each TBF in which the RLC endpoint is the receiver. The receive window state variable can take on the value 0 through SNS −1.        
In case of mobile stations with multislot capability, windows for EGPRS TBFs can assume the size values specified in Table 1 illustrated in FIGS. 2a and 2b, depending on the number of timeslots allocated to the TBF. In Table 1 (see subclause 9.1.9) the grey area for a given timeslot allocation represents an usable window size, optionally comprised within 64 RLC/MAC blocks and the Maximum indicated value. In any case, the window size can not assume a value lower then 64 RLC Blocks. The window size determines the receive window at receiving RLC/MAC Layer entity.
Due to “in sequence RLC delivery property”, RLC Blocks received inside the receive window can not be delivered to upper layers (LLC Layer) even if all/the RLC data corresponding to an LLC Frame have been completely received. This behavior adds additional delay to received data, becoming a drawback for delay sensitive services (e.g. VoIP). The aim of non-persistent mode is to prevent the transmitter from persistent retransmissions in case one or more data blocks are badly received, and the receiver has signaled back the side events. According to 3GPP TS 44.060, paragraph 9.1, the following arguments (updated with the most recent knowledge, although not yet standardized by 3GPP) further help the comprehension of the technical problem (italics is reported from the specification):                “A TBF is comprised of two peer entities, which are the RLC endpoints. Each RLC endpoint has a receiver that receives RLC/MAC blocks. Each RLC endpoint also has a transmitter that transmits RLCMAC blocks. A bearer is comprised of one transmitting RLC endpoint and at least one receiving RLC endpoint. The transmitting RLC endpoint transmits RLC/MAC data and control blocks and may receive RLC/MAC control blocks. Each receiving RLC endpoint receives RLC/MAC data and control blocks and may transmit only RLC/MAC control blocks. The bearer can operate in RLC non-persistent mode” An RLC data block is considered received, when it is received in a layer 1 frame with consistent parity bits (in EGPRS TBF mode: header and relevant data parity bits) and correctly addresses the receiving RLC endpoint.        In RLC acknowledged mode, the receive window is defined by the receive window state variable V(Q) in the following inequality of V(Q)<BSN<V(Q)+WS] modulo SNS All BSNs which meet that criteria are valid within the receive window.        In RLC unacknowledged mode, all values of BSN are within the receive window.        In RLC non-persistent mode, the receive window is determined after recalculating the receive state variable V(R) (as described in sub-clause 9.1.5) and the corresponding receive window state variable V(Q) (as described in sub-clause 9.1.6). All BSNs which meet the following inequality modulo SNS are valid within the receive window.        
Each endpoint's transmitter has a transmit window of size WS. In RLC acknowledged mode and in RLC non-persistent mode, the transmit window is defined by the send state variable V(S) in the following inequality: modulo SNS, where modulo SNS <=WS. All BSNs which meet that criteria are valid within the transmit window. In RLC unacknowledged mode, all values of BSN are within the transmit window.
According to 3GPP TS 44.060, clause 9.3.4: ‘The transfer of RLC data blocks in the RLC non-persistent mode includes non-exhaustive retransmissions. The block sequence number (BSN) in the RLC data block header is used to number the RLC data blocks for reassembly. The receiving side sends DOWNLINK ACK/NACK messages to inform the transmitting side of the status of the reception and to convey neighboring cell measurements”.
According to 3GPP TS 44.060, paragraph 9.1.12: “During RLC non-persistent mode operation, received upper layer PDUs shall be delivered to the higher layer in the order in which they were originally transmitted. Nevertheless, since some RLC data units may not be received, some upper layer PDUs may be re-assembled and delivered to the higher layer erroneously. During media/multimedia bearer each receiving RLC endpoint shall use RLC data units up to the one characterized by BSN=V(Q)−1 when reassembling upper layer PDUs, even if some RLC data units are missing. Fill bits having the value V shall be substituted for RLC data units not received . . . ”.
Despite non-persistent mode of operation, also the minimum window size causes an intrinsic latency. An example is useful to clarify the matter. Let us suppose WS=64 and until BSN=9, included, all RLC/MAC radio blocks are correctly received with cadence of 20 ms: hence V(Q)=IO. Let us suppose now that all blocks successive to 10 (namely 11, 12, 13 . . . ) arrive to the receiver and that block with BSN=10 is retransmitted for X times without ever being correctly received. The receiver, before considering the BSN=10 as not more receivable, and then deliver the windowed data to the upper LLC protocol layer for “in sequence” delivering, must receive the radio block with BSN=74 (namely V(R)=75). Because of non-persistent mode operation, blocks having a BSN<V(R) WS will be discarded. In the specific, BSN<75 64 (<1 1) corresponding to BSN=10 will be discarded. At this point all windowed data are delivered to the upper layer with a delay of 20 ms×64=1,280 ms affecting all windowed data (packets and voice), obviously unacceptable for real-time media or multimedia services.